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Abstract 



The infrastructure (2) is used for a control system with a number of monitoring devices with data processing 
components, distributed at different monitoring points within the power plant and incorporates a number of 
distributed object manager components (4.. .16), each having at least one object manager, with incorporated 
redundancy The infrastructure monitors the operating condition of each redundant object manager 
component (10a,10b,12a,12b), or object manager (22a,22b, 24a,24b), with access to all other object 
manager components. 
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@ Infrastrukturfur ein System von verteilten Objektmanager-Komponenten 

(57) Infrastruktur (2) fur ein System von verteilten Objekt- 
manager-Komponenten (4 bis 16), insbesondere fur ein 
Leitsystem einer Kraftwerksanlage, mit einer Anzahl von 
rechnergestutzten Objektmanager-Komponenten, die je- 
weils mindestens einen Objektmanager ausfuhren, wobei 
fur redundant ausgefuhrte Objektmanager-Komponenten 
(10a, 10b, 12a, 12b) oder Objektmanager (22a, 22b f 24a, 
24b) der Zustand "prozefcfuhrend" und entsprechend 
"nicht-prozefSfuhrend" uberwacht und f u r alle iibrigen 
Objektmanager-Komponenten (4, 6, 8, 14, 16) zuganglich 
ist. 
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Beschreibung 

Die Erfindung bezieht sich auf eine Infrastruktur fiir ein 
System von verteilten Objektmanager-Komponenten, insbe- 
sondere fur ein Leitsystem einer Kraftwerksanlage, mit ei- 
ner Anzahl von rechnergestiitzten Objektmanager-Kompo- 
nenten. 

In einer Kraftwerksanlage sollen t)berwachungseinrich- 
tungen die aktuellen Betriebszustande der Anlage erkennbar 
machen und Abweichungen von einem Sollzustand melden. 
Dazu ist eine umfangreiche MeBwerterfassung der Betriebs- 
zustande aller Anlagenteile, eine umfangreiche und der 
Komplexitat der Anlage gerecht werdende MeBwertbewer- 
tung und eine unter hoher Inforrnationsverdichtung visuali- 
siert aufbereitete Statusanzeige fur die Betriebszustande der 
Anlagenteile erforderlich. 

Diese vorstehend genannten Aufgaben soli ein Leitsy- 
stem erfullen. Bedingt durch die hohe Komplexitat solcher 
technischen Anlagen muB ein solches Leitsystem einfach 
und geradlinig strukturiert sein. Dies bedeutet zum einen, 
daB Anlagenteile mittels des Leitsy stems iiberwachbar und 
einstellbar sind und zum anderen, daB neue und/oder uberar- 
beitete und geanderte Kontroll-, Einstell- und/oder Aus- 
werteoptionen in einfacher Weise in das bestehende Leitsy- 
stem und seine Architektur integrierbar sind. 

Aus net 40 (1986), Heft 9, Seiten 338-342, insbesondere 
Bild 2, ist ein "Ringnetz mit Token Access" bekannt Bild 3 
zeigt die Moglichkeit, einen zusatzlichen gegenlaufigen 
Ring zu integrieren. 

Aus Elektronik 7/31.3.1989, Seiten 52-58, insbesondere 
Bilder 4 und 5, sind lokale Netze mit "Ringstruktur" und 
"Doppelringstruktur" bekannt. Als Zugriffsverfahren fur lo- 
kale Netze sind insbesondere von Seite 53, dritter Absatz, 
das "Token-Ring-" und das "Token-Bus-Verfahren" be- 
kannt. 

Aus Europhysics Conference on Control Systems for Ex- 
perimental Physics, Proceedings (CERN 90-08), Villars-sur- 
Ollon, Switzerland, 28. Sept. - 2. Oct. 1987, Seiten 15-20, 
published: CERN, Geneva, Switzerland 1990, vergleiche 
insbesondere Fig. 2, ist ein Steuer- und Regelungssystem 
mit einem 'N-zu-N Token Ringnetz" bekannt. 

Aus EP 0 604 091 A2, insbesondere Fig. 10, ist ein 
"Ringnetz" bekannt. AuBerdem ist insbesondere aus 'Fig. 9 
ein "Server" bekannt. ' 

Aus Elektronik 25/1994, Seiten 58-64, vergleiche insbe- 
sondere Seite 59, rechte Spalte, ist das "Client- Server- Kon- 
zept" bekannt. 

In der alteren Anmeldung WO 95/30937 ist ein Leitsy- 
stem, insbesondere ein rechnergestutztes Leitsystem, vorge- 
schlagen, bei dem eine hohe Konfigurierbarkeit einer die 
MeBwerte be- und auswertenden Ebene innerhalb des Leit- 
systems gegeben ist. Dies wird im einzelnen dadurch er- 
reicht, daB die Leitebene modular aufgebaut ist und mehrere 
Funktionsbausteine umfaBt, die entsprechend ihrer jeweili- 
gen Funktion Eingangswerte verarbeiteri und unter Beriick- 
sichtigung einer Anzahl von zu losenden technischen An- 
wendungen untereinander verknupfbar sind, Aufgrund die- 
ses modularen Aufbaus der Leitebene und ihrer Systeme 
sind eine nahezu beliebige Strukturierbarkeit und graphi- 
sche Konfigurierbarkeit des Leitsystems in dieser Ebene ge- 
geben. Es konnen jederzeit Funktionsbausteine modifiziert, 
erganzt, weggenommen' oder neu verkniipft werden, um 
eine zu losende technische Anwendung, wie z, B, die Pro- 
zeBfuhrung bestimmter Anlagenteile, die ProzeBinforma- 
tion, die Kenngrofienberechnung oder die Bilanzierung, 
durchfuhren zu konnen. Die dabei verarbeiteten Eingangs- 
werte konnen die unmittelbar von der Automadsierungs- 
ebene erhaltenen MeBwerte, bereits mit einer Zugehdrig- 
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keitsfunktion bewertete MeBwerte, Zwischenresultate ande- 
rer Funktionsbausteine und uber die Betriebsfuhrungsebene 
vorgebbareprojekUerbare Parameter sein. 

Bei einem solchen meist rechnergestiitzten Leitsystem ist 
5 es wiinschenswert, wenn die Leitebene und die mit der Leit- 
ebene verbundenen Ebenen innerhalb einer gemeinsamen 
Systemumgebung, einer sogenannten Infrastruktur, gefuhrt 
sind. Hierzu ist es bekannt, ein Betriebssystem, vorzugs- 
weise ein handelsiibliches Betriebssystem, wie z. B. UNIX 
to oder OS 2, zu verwenden, das die Betriebsfuhrungsebene, 
die Leitebene und die Automatisierungsebene sowie einen 
Datentransfer zwischen diesen Ebenen unterhalt. Bei sol- 
chen Betriebssystemen ist es daruber hinaus wiinschens- 
wert, wenn die freie Verknupfbarkeit der in der Leitebene 
15 angeordneten Funktionsbausteine unterstiitzt wird, und 
wenn eine weitgehende Unabhangigkeit des Leitsystems 
von der Innovadonsgeschwindigkeit der Rechner-Hardware 
erreicht wird. 

Derzeit handelsubliche Betriebssysteme, wie z. B. UNIX 
20 oder OS 2, sind jedoch uberfordert, wenn es im Rahrnen ei- 
ner Infrastruktur fiir ein System von verteilten Objektmana- 
ger-Komponenten darum geht, beispielsweise ein aus einer 
Anzahl von rechnergestiitzten Objektmanager-Komponen- 
ten bestehendes verteiltes System hochzufahren. Eine nicht 
25 zufriedenstellende derzeidge Losung sieht hierzu einen 
iibergeordneten Rechner vor, der zu Beginn des Anlaufs die 
Informadonen uber die gesarnte Konfiguradon aller existie- 
renden Objektmanager-Komponenten kennt. Bedingt durch 
die Komplexitat einer Kraftwerksanlage kommt es zu Stb- 
30 rungen, wenn beispielsweise der iibergeordnete Rechner ge- 
stort ist, oder wenn die Datenverbindungen zudiesern iiber- 
geordneten Rechner gestort sind, oder wenn sich an der Ge- 
samtkonfiguradon noch kurzfristig vor dem Anlaufen etwas 
geandert hat und diese Anderungen noch. nicht zu Beginn 
35 des Anlaufs beriicksichtigt worden sind. 

Weitere Probleme treten auf, wenn einzelne Objektmana- 
ger-Komponenten redundant ausgefuhrt sind. Die Probleme 
werden durch die Tatsache verursacht, daB der ubergeord- 
nete Rechner zu jeder Zeit Kenntnis davon haben muB, wel- 
40 che Objektmanager-Komponente prozeBfuhrend und wel- 
che Objektmanager-Komponente nicht-prozeBfiihrend ist. 

Der Erfindung liegt daher die Aufgabe zugrunde eine In- 
frastruktur fur ein System von verteilten Objektmanager- 
Komponenten anzugeben, mit der jederzeit sichergestellt ist, 
45 daB eine storungsfrei vorliegende Informadon uber den Zu- 
stand von redundant ausgefuhrten Objektmanager-Kompo- 
nenten vorliegt. 

Diese Aufgabe wird erfindungsgemaB dadurch gelost, 
daB eine Infrastruktur fur ein System von verteilten Objekt- 
50 manager- Komponenten mit einer Anzahl von rechnerge- 
stiitzten Objektmanager-Komponenten, die jeweils minde- 
stens einen Objektmanager ausfiihren, vorgesehen ist, wobei 
fiir redundant ausgefuhrte Objektmanager-Komponenten 
oder Objektmanager der Zustand "prozeBfuhrend" und ent- 
55 sprechend "nicht-prozeBfuhrend" uberwachbar und fur alle 
iibrigen Objektmanager-Komponenten zuganglich ist. 

Hierbei wird unter einer Objektmanager-Komponente 
beispielsweise eine Workstation, eirf Personal-Computer, 
Automatisierungssy steme, wie z. B. die Siemens-Siematic 
60 S5 und S7, oder vergleichbare rechnergestiitzte Einrichtun- 
gen verstanden. Unter einem Objektmanager werden insbe- 
sondere bei einer Kraftwerksanlage die folgenden Kompo- 
nenten verstanden. Es sind dies das Man-Machine-Interface, 
das Archiv, die Protokolliste, die Verarbeitungseinrichtung 
65 fur die Bausteintechnik, eine Datenbank fiir Beschreibung s-, 
Symptom- und Diagnose texte und ein sogenannter AS-Re- 
prasentant, der das Automadsierungssystem, also die 
Schnitts telle zwischen KraftwerksprozeB und Datenverar- 
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beitung, stiitzt. 

Auf diese Weise ist es moglich, daB jede Objektmanager- 
Komponente in Folge der entsprechenden Ausgestaltung der 
Infrastruktur Kenntnis iiber den aktuellen Redundanz-Zu- 
stand der am System beteiligten Objektmanager-Kompo- 
nenten und Objektmanager hat. Fehler, die durch eine iiber- 
geordnete Uberwachungsinstanz auftreten konnen, sind auf 
diese Weise eliminiert. 

In vorteilhafter Weise kann ein Zustandubergang einer 
Objektmanager-Komponente oder eines Objektmanagers 
bei Vorliegen eines Ausfallereignisses selbsttatig erfolgen. 
Dies bedeutet insbesondere, daB die Infrastruktur eine fur 
alle Objektmanager-Komponenten zugaagliche Meldung in 
auf ebensolche.Meldungen wartende Schnittstellen der Ob- 
jektmanager-Komponenten schreibt. 

In weiter zweckmiiBiger Weise ist die Infrastruktur derart 
ertiichtigt, daB die tibermittlung eines datenlesenden Auf- 
trages an den prozeBfuhrenden Server erfolgt, und/oder das 
die t)bermittlung eines datenschreibenden Auftrages an alle 
zueinander redundanten Objektmanager-Komponenten oder 
Objektmanager erfolgt Auf diese Weise ist es gewahrleistet, 
daB ein datenlesender Client unverzuglich bedient wird bzw. 
daB eine redundant ausgefuhrte, aber derzeit nicht-prozeB- 
fiihrende Objektmanager-Komponente oder Objektmanager 
jederzeit in der Lage ist, an die prozeBfiihrende Stelle zu tre- 
ten. 

Eine weitere vorteilhafte Ausgestaltung der Erfindung 
sieht es vor, daB zum Aufdaten von Objektmanagem auf 
wiederanlaufenden redundanten Objektmanager-Kompo- 
nenten der fuhrende Server auf Auftrag ein konsistentes Ab- 
bild seiner ProzeBdaten erstellt und zum. aufrufenden Client 
iibertragt Auf diese Weise enthalt der auf der wiederanlau- 
fenden redundanten Objektmanager-Komponente instal- 
lierte Objektmanager nach definierter Aufforderung zu ei- 
nem definierten Zeitpunkt alle fur den Betrieb des Objekt- 
managers erforderiiche Daten. Es entstehen also keine Da- 
tenliicken oder Fehler durch die UbermitUung nicht aktuel- 
ler ProzeBdaten. 

In besonders einfacher Weise laBt sich die Erfindung aus- 
gestalten, wenn eine Objektmanager-Komponente oder ein 
Objektmanager in dem jeweiligen Server-Hauptteil eine 
Schnittstelle aufweist, die eine Anderung des Redundanz- 
Zustandes der entsprechenden Komponente oder des ent-. 
sprechenden Objektmanagers erfaBt. 

Ausfuhrungsbeispiele der Erfindung werden anhand einer 
Zeichnung naher erlautert." Dabei zeigen: 

Fig. 1 in schemadscher Darstellung eine Infrastruktur fiir 
ein verteiltes System von Objektmanager-Komponenten; 

Fig. 2 in schematischer Darstellung einen in die Infra- 
struktur eingebetteten Objektmanager; 

Fig. 3 in schematischer Darstellung den Uberwachungs- 
mechanismus der gemaB Fig. 1 dargestellten Infrastruktur; 

Fig. 4 in schematischer Darstellung den tjberwachungs- 
mechanismus gemaB Fig. 3 bei dem Ausfall einer Objekt- 
manager-Komponente; und 

Fig. 5 in schematischer Darstellung den Uberwachungs- 
mechanismus in der Infrastruktur gemaB den Fig. 3 und 4 in 
zwei Uberwachungsebenen. 

In den Fig. 1 bis 5 haben gleiche Teile die gleichen Be- 
zugszeichen. 

In der in Fig. 1 gezeigten schematischen Darstellung er- 
kennt man die Infrastruktur 2 fur ein verteiltes System 18 
von Objektmanager-Komponenten 4 bis 16 als schrafflert 
unterlegte Flache. Das System 18 ist als Leitsystem fur eine 
Kraftwerksanlage vorgesehen. Die Objektmanager-Kompo- 
nenten 4 bis 16 konnen Datenverarbeitungsanlagen beliebi- 
ger Art, wie z. B. GroBrechner, Workstations, Personal- 
Computer und Host-Rechner jeglicher Art, sein. Auf den 



einzelnen Objektmanager-Komponenten 4 bis 16, von de- 
nen die Komponenten 10a und 10b sowie 12a und 12b red- 
undant ausgefuhrt sind, werden Objektmanager ausgefuhrt. 
Unter Objekten werden Daten jeglicher Art, wie z. B. bi- 
5 nare Signale, hexadezimale Signale, wie z. B, Real-Werte, 
Integer-Werte, Boolean- Werte oder String-Ketten, vers tan- 
den. Objektmanager sind also solche hardwaremaBig oder 
auch softwaremaBig realisierte Einheiten, die Objekte belie- 
biger Art verwalten. Objektmanager sind beispielsweise das 
10 Man-Machine-Interface (MMI) 20, das Archiv 22 zur Auf- 
zeichnung der Geschichte des Kraflwerks (redundant ausge- 
fuhrt als 22a und 22b), der Protokollverwalter 24 (ebenfalls 
redundant ausgefuhrt als 24a und 24b); der Verwalter 26 fur 
die Datenverarbeitung der in Bausteintechnik vorgesehenen 
|5 und hier nicht weiter dargestellten Leitebene, die Datenbank 
28 fur Beschreibungsdaten und der Reprasentant 30 des Au- 
tomatisierungssys terns. We beispielsweise anhand des Re- 
prasentanten 30 des Automatisierungssystems gezeigt, kann 
ein Objektmanager auch auf mehreren Objektmanager- 
20 Komponenten, hier die Komponenten 4 bis 8 und 16, gleich- 
zeitig ausgefuhrt werden. 

Beim Anlauf des Systems 18 werden von einer dezentral 
angeordneten Initialisierungsdatei32 die Anlaufdaten in die 
Infrastruktur 2 eingegeben. Jeder der Objektmanager-Kom- 
25 ponenten 4 bis 16 hat einen Teil seiner zur Verfugung ste- 
henden Rechenleistung reserviert, um die Infrastruktur 2 in 
hardwaremaBig verschalteter Form oder auch in software- 
maBig installierter Form zu betreiben. Die Anlaufdaten der 
InitiaHsierungsdatei 32 enthalten einen dezentralen Algo- 
30 rithmus, nach dem in einer ers ten. Phase des Anlauf s die Ob- 
jektmanager-Komponenten 4 bis 16 untereinander Kontakt 
aufnehmen und der Infrastruktur 2 und damit alien an der In- 
frastruktur 2 beteiligten Komponenten 4 bis 16 ihre lokal in- 
stallienen Objektmanager 20 bis 30 bekannt. Nach dieser 
35 Kontaktaufnahme sind auf jeder Objektmanager-Kompo- 
nente 4 bis 16 alle anlaufenden Objektmanager-Komponen- 
ten und alle dort existierenden Objektmanager bekannt. 

In einer zweiten Phase werden mittels der Infrastruktur 2 
auf den Objektmanager-Komponenten 4 bis 16 die lokal in- 
40 stallierten Objektmanager 20 bis 30 gestartet Die Infra- 
struktur 2 wartet femer darauf, daB die Objektmanager 20 
bis 30 ihre Verfiigbarkeit als Server bekannt geben, und ak- 
tualisiert - auch wenn der ttberwachungsmechanismus ei- 
nen Abbruch eines Objektmanagers erkannt hat - den neuen 
. 45 Zustand zusarnmen mit einer detaillierten Adressinforma- 
tion auf alien Objektmanager-Komponenten 4 bis 16. In ei- 
ner dritten Phase werden die Objektmanager 20 und 26 auf 
den redundant Yorliegenden Objektmanager-Komponenten 
10a, 10b bzw. 12a, 12b gestartet. Dabei datet sich der je- 
50 weils fuhrende Redundanzpartner am alien Objektmanager- 
Komponenten 4 bis 16 gemeinsamen AnlaufprozeB auf und 
der oder die nicht fuhrenden Objektmanager daten sich beim 
jeweils fuhrenden Objektmanager auf. 

Die Infrastruktur 2 unterstiitzt auch eine weitere Anlaufsi- 
55 tuation, bei der sich eine abgebrochene Objektmanager- 
Komponente. beispielsweise die Komponente 6, in ein eta- 
bliertes Teilsystem, bestehend aus den Komponenten 4, 8 
bis 16, wieder eingliedert. Die sich eingliedemde Objektma- 
nager-Komponente 6 stellt sich zunachst bei einer schon im 
60 Teilsystem etablierten Objektmanager-Komponente, bei- 
. spielsweise der Komponente 8, vor, indem die Objektmana- 
ger-Komponente 6 ihre lokal ihstallierten Objektmanager, 
hier der Reprasentant 30 des Automatisierungssystems, mit- 
teilt. Die lokale Infrastruktur der Objektmanager-Kompo- 
65 nente 8, dargestellt durch die schraffierte Flache innerhalb 
des Symbols fur die Objektmanager-Komponente 8, macht 
die sich eingliedemde Objektmanager-Komponente 6 im 
etablierten Teilsystem bekannt. Die sich eingliedemde Ob- 
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jektmanager-Komponente 6 erhalt von der Komponente 8, 
bei der sie sich vorgestellt hat, die Informationen iiber die 
Zustande und Adressen der Objektmanager-Komponente 4, 
8 bis 16 des etablierten Teilsystenis und der darauf installier- 
ten Objektrnanager. Auf diese Weise wird die Objektmana- 
ger-Komponente 6 in das etablierte Teilsystem eingegliedert 
ohne da6 eine iibergeordnete Instanz, beispielsweise ein 
Leitrechner, vorgesehen ist, der die Konfiguration, Zustande 
und Adressen der ubrigen Objektraanager-Komponenten 
kennt. Diese Informationen sind vielmehr auf jeder Objekt- 
manager-Kornponente 4 bis 16 im lokalen Teil der Infra- 
struktur 2 enthalten, so daB auch jede Anderung des Status 
einer Objektmanager-Komponente oder eines Objektmana- 
gers alien Objektmanager-Komponenten unmittelbar zu- 
ganglich ist, Dies wirkt sich besonders vorteiihaft auf die 
Serverfunktionen der Objektrnanager und auf die Kenntnis 
deren Verfugbarkeit im gesamten System 18 aus. In beiden 
Anlaufsituationen startet die Infrastruktur 2 die lokal instal- 
lierten Objektrnanager, in dem sie deren Inatialisierungspro- 
zesse erzeugt. Objektrnanager, die dem System 18 keine 
Serverleistung zur Verfiigung stellen, sind mit diesem 
Schritt sofort verfugbar. 

Der Abbruch eines Objektmanagers 20 bis 30 wahrend 
des Anlaufs wirkt sich abhangig vom Vorhandensein einer 
Redundanz auf den Zustand der entsprechenden Objektma- 
nager-Komponente 4 bis 16 aus: Bei vorhandener Redun- 
danz werden die schon aktiven Objektrnanager beendet und 
die Objektmanager-Komponente wird als "abgebrochen" fur 
alle ubrigen Objektmanager-Komponenten zuganglich mar- 
kiert. Ohne vorhandene Redundanz wird der Anlauf der Ob- 
jektmanager-Komponente fortgesetzt. Nur der vom Ab- 
bruch betroffene Objektrnanager wird als "abgebrochen" 
markiert. 

' In Fig. 2 ist in schematischer Darstellung. gezeigt, in wel- 
cher Weise ein Objektrnanager, hier beispielsweise der Ob- 
jektrnanager 30, aufgebaut und. in die Infrastruktur 2 einge- 
bunden ist. Im vorliegenden Fall weist der Objektrnanager 
30 zwei Qient-Schnittstellen 32, 34, einen Init-Server 36, 
'einen Server-Hauptteil 38, einen Server-Ubertragungsteil 40 
und einen Server 42 fiir Projektierungsdienste auf. 

Uber die Client-Schnittstellen 32, 34, die &uch als 
Schnittstelle Client-Infrastruktur 2 bezeichnet werden kann, 
werden Auftrage iiber die Infrastruktur 2 an Server ausgege- 
ben, und es konnen Antworten vom Server iiber die Infra- 
struktur 2 in der Schnittstelle empfangen werden. Hierbei 
kann die Schnittstelle als Mehrfachwartestelle ausgefuhrt 
sein, so daB es moglich ist, auf die Ergebnisse verschiedener 
Auftrage unabhangig voneinander warten zu konnen, was 
sich besonders vorteiihaft auf die Synchronisation von Da- 
tenaustausc h vorgangen auswirkt. 

Der Init-S erver 36 wird beim Anlauf des Objektmanagers 
30 aufgerufen. Dieser Init-Server 36 startet uud iiberwacht 
alle weiteren Prozesse, die auf dem Objektrnanager 30 aus- 
gefuhrt werden. Der Init-Server 36 teilt alien ubrigen Pro- 
zessen dariiber hinaus wichtige Konfigurations- und Adress- 
inforrnationen mit. Falls der Objektrnanager 30 beendet 
werden soil, wird dies dem Init-Server 36 von der Infra- 
struktur 2 uber ein entsprechendes Signal, beispielsweise 
ein UNIX-Signal, mitgeteilt. Das Beenden des Objektmana- 
gers 30 wird der Infrastruktur 2 durch das Beenden des Ink- 
Servers 36 mitgeteilt. 

Der Server-Hauptteil 38 stellt dem Server fur alle "Nutz- 
funktionen" des Objektmanagers 30 dar. Im Server-Haupt- 
teil 38 ruft das Hauptprogramm nach der eigenen Initialisie- 
rung durch den Init-Server 36 eine Uberwachungsfunktion 
auf. Diese Uberwachungsfunktion wartet uber die gesamte 
Lebensdauer des Server-Hauptteils 38 auf Client-Auftrage 
und ruft entsprechend dieser Auftrage Server-Funktionen 
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auf, d. h. der Server-Hauptteil 38 wartet in einer Wartestelle 
in der Infrastruktur 2 auf entsprechende Client-Auftrage. 
Diese Funktion ist daher eine Art vorgeschobener Horchpo- 
sten aus dem Objektrnanager 30 heraus in die Infrastruktur 
5 2. Erst wenn der Server-Hauptteil 38 beendet wird, verlaSt 
diese Funktion die Infrastruktur 2 und kehrt in das Haupt- 
programm zuruck. 

Der Server-Ubertragungsteil 40 stellt einen in den Prozefi 
des Objektmanagers 30 eingebundenen Funktionssatz dar, 
10 uber den Server antworten (z.B. fur kontinuierliche Auf- 
trage) abgegeben werden. Der Server-Ubertragungsteil 40 
ubertragt, falls sich ein Client uber den Server-Hauptteil 38 
angemeldet hat, die gewunschten Ereignisse oder sonstige 
Ereignisse von kontinuierlichen Auftragen. 
15 Der Server 42 fiir Projektierungsdienste wartet nach sei- 
ner Aktivierung auf Projektierungsauftrage und legt die Pro- 
jektierungsinformation in eine Objektrnanager spezifische 
Datenbasis ab oder gibt sie an die innerhalb des Objektma- 
nagers 30 betroffenen Prozesse weiter. 
20 Die Infrastruktur 2 iiberwacht und steuert die gesamte 
Kommunikation in einer Weise, daB jedes Objekt ein inter- 
nes Kennzeichen und einen Auspragungstyp umfaBt, an- 
hand deren der Objektrnanager, beispielsweise Objektrnana- 
ger 30, ermittelbar ist, der dieses Objekt verwaltet. Hierbei 
25 wird unter einem Objekt jede Information verstanden, die in 
einer Datenverarbeitungsanlage zur Kommunikation von 
Prozessen ausgetauscht oder iibertragen wird. Mit dem Aus- 
pragungstyp eines Objektes ist beispielsweise zunachst ge- 
meint, ob dieses Objekt der verfahrenstechnischen Welt, der 
30 leittechnischen Welt oder der anlagentechnischen Welt zu- 
zuordnen ist. Weiter beinhaltet der Auspragungstyp eine 
Klassifizierung des Objekts nach . seiner Aufgabenumge- 
bung, beispielsweise kann ein Objekt Alarm- oder Toleranz- 
meldungen, Hardware-Geratefehlern, Busfehlern oder 
35 Funktionsfehlern zugeordnet sein. Das interne Kennzeichen 
ist nicht gleichbedeutend mit dem BegrirT."Adresse", weil 
das interne Kennzeichen keinerlei Ortsinformation uber die 
Lage des Objektes besitzt. Dariiber hinaus kann dem inter- 
nen Kennzeichen nicht eindeutig eine Adresse zugeordnet 
40 werden, denn verschiedene Daten eines Objekts konnen von 
verschiedenen Objektmanagern 20 bis 30 verwaltet werden, 
die unter Umstanden auf verschiedenen Objektmanager- 
Komponenten 4 bis 16 angesiedelt sind. Auf diese Weise 1st 
mit besonders vorteilhafter Wirkung eine Adressierung von 
45 Objekten anhand ihrer Eigenschaften, d. h. eine assoziative 
Adressierung, moglich. Hierdurch vereinfacht sich die Pro- 
jektierung, weil ganze Objekt- Klassen ausgewahlt werden 
konnen, ohne daB deren Lage im einzelnen einem Objekt- 
rnanager oder einer Objektmanager-Komponente bekannt 
50 sein miissen. So kann beispielsweise von dem Objektrnana- 
ger 4, dem Man-Machine- Interface, das Kommando abge- 
setzt werden "Suche Leittechnikfehler" . Auf diese Weise 
sind in dem gesamten System 18 nur solche Objekte ange- 
sprochen, die gemali ihres internen Kennzeichens und des 
55 Auspragungstyps in die Signalklasse "Leittechnikfehler" 
hineinfallen. 

Die Kommunikation im System 18 kann zum einen eine 
von einem Server-gesteuerte diskontinuierliche Kommuni- 
kation und zum anderen eine von einem Client-gesteuerte, 

60 kontinuierliche Kommunikation sein. Bei der Server-ge- 
steuerten Kommunikation muB der Client den Umfang der 
Ergebnisse nicht kennen, Teilergebnisse konnen iibertragen 
werden, wenn sie anfallen. Durch die Client-gesteuerte 
Kommunikation wird das gesamte Kommunikationsauf- 

65 kommen im System 18 verringert, weil keine Auftragswie- 
derholungen notwendig sind. Die Infrastruktur 2 ist hierbei 
derart konzipiert, daB bei dem Vorliegen eines Kommunika- 
tionsauftrages eines Clienten alle an diesem Auftrag betei- 
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ligten Server unmittelbar und nur einmalig zur Datenaus- 6 kennt die Konfiguradon dieser Kornponente und teilt uber 

gabe aufgefordert sind. Gleichzeitig kann mit einer solchen die Infrastruktur 2 den verbleibenden Objektmanager-Korn- 

Aufforderung eine Synchronisadonsaufforderung an alle be- ponenten alle mit der Objektmanager- Kornponente ausge- 

teiligten Server ergehen. Weiter kann in besonders zweck- fallenen Objektmanager mit. Dies ist im vorliegenden Fall 

maBiger Weise die Meldung des Vollzugs der Synchronisa- 5 der auf der Objektmanager-Komponente 6 durchgefiihrte 

don an den Client erst dann ergehen, wenn die Bereitschaft Objektmanager 30. GemaB der vorgegebenen Algorithms 

zur Datenausgabe alter verfugbaren Server vorliegt, so daB hat die Objektmanager-Komponente 4 nun nicht die Objekt- 

auch hier das Kommunikationsaufkommen besonders ge- manager- Kornponente 6 als Server, sondem die Objektma- 

ring ist, weil keine Nachfragen des Clients nach besdmmten nager-Komponente 8, so daS die im verbleibenden System 

Ergebnissen an einzelne Server ergehen. 10 aktiven Objektmanager-Komponenten 4, 8 bis 16 wieder ei- 

Eine weitere vorteilhafte Ausgestaltung der Infrastruktur nen logischen Oberwachungsring bilden. Will sich die Ob- 

2 sieht es vor, daB eine Wiederanmeldung eines noch anste- jektmanager-Komponente 6 wieder in das System einglie- 

henden Auftrages eines Clienten bei einem wiederverfugbar dem, meldet sie sich bei der Objektmanager-Kornpunenie 8 

gewordenen Server vorgesehen ist. Die Infrastruktur 2 stellt . an, gibt ihre lokal installierten Objektmanager, hier der Qb- 

also Ressourcen bereit, die alle im System 18 eingegange- 15 jektmanager 30, bekannt und erfahrt von der Objektmana- 

nen Auftrage erfaBt und speichert, falls ein Server zur. Auf- ger-Komponente 8 die Konfiguradon und Zustande aller ub- 

tragserledigung nicht verfligbar ist. Da die Infrastruktur rigen Objektmanager-Komponenten. Dies ist durch die ge- 

gleichzeidg jede Zustandsanderung eines Servers beziiglich strichelten Pfeile 44 symbolisiert. 

seiner Verfugbarkeit erfaBt, wird eine Auftragserledigung Ein weiterer Spezielfall ist .fiir die Objektmanager-Kom- 

unmittelbar nach Wiederverfugbarkeit eines Servers "ange- 20 ponenten 10a und 10b dargestellt. Diese Kornponente ist 

mahnt" . redundant ausgefuhrt. Im gezeigten Fall ist die Kornponente 

Die Infrastruktur 2 ist weiter in der Lage einen Kommuni- 10a ausgefallen. Der Server dieser Kornponente 10a kennt 

kadonsauftrag beziiglich der Parameterversorgung zu prii- die Konfiguradon dieser Kornponente und die auf dieser 

fen und den Auftrag bei fehlerhafter Parameterversorgung Kornponente lokal installierten Objektmanager, hier das 

unter Angabe eines Fehlercodes abzulehnen. Auf diese 25 Man-Machine-Interface 20, und teilt den ubrigen Objektma- 

Weise konnen beispielsweise Fehler vermieden werden, nager-Komponenten, die mit der Objektmanager-Kompo- 

wenn bei der Suche nach einem Leittechnikfehler in der ver- nente ausgefallenen Objektmanager mit. Hierbei ist es die 

fahrenstechnischen oder anlagentechntschen Welt gesucht Infrastruktur 2, die ein fur alle Objektmanager-Kouiponen- 

wird. Ein solcher Fehler ist nur in der leittechnischen Welt ten zugangliches Ereignis generiert, das insbesondere den 

zu finden, d. h. also bei den Datenquellen und Senken, die 30 verbleibenden Komponenten mitteilt, ob eine Objektmana- 

vom Auspragungstyp her mit der Fehlerklasse iibereinstim- ger-Komponente "prozeBfuhrend" oder "nicht-prozeBfuh- 

men. rend" ist bei redundanter Ausfuhrung der jeweiligen Kom- 

Hierbei kann das dynamische Verhalten der Erledigung ponente. 

eines Kommunikadonsauftrages nachvollziehbar und verifi- Nach dem Ausfall der Kornponente 10a erfolgt der Zu- 

zierbar sein. Eine solche Funkdon kann beispielsweise uber 35 standsubergang der Objektmanager-Komponente von 

den Protokollverwalter 24 an die dem Man-Machine-Inter- "nicht-prozeBfuhrend" nach "prozeBfuhrend" der Kompo- 

face zugeordneten Drucker ausgegeben werden. Dies ist in nente 10b selbsttadg. Hierbei kann es weiter* vorgesehen 

der Projektierungsphase besonders bedeutsarn, wenn man sein, daB zum Aufdaten von Objektmanagem auf wiederan- 

nachvollziehen will, welche Daten woher geladen wurden, laufenden redundanten Objektmanager-Komponenten der 

und in welcher Weise daraus Ergebnisse berechnet wurden, 40 prozeBfuhrende Server auf Auftrag ein konsistendes Abbild 

und wohin die Ergebnisse gesendet wurden. . seiner.ProzeBdaten erstellt und zum aufrufenden Client, hier 

In-Fig. 3 ist der Uberwachungsmechanismus der Objekt- der Server der ausgefallenen Objektmanager-Komponente 

manager-Komponenten 4 bis 16 in dem System 18 darge- 10a, iibertragt. Urn den Redundanz-Zustand einer Objekt- 

stellt. Der Mechanismus wird anhand der Objektmanager- manager-Komponente fur die ubrigen Komporienten zu- 

Komponenten 4 bis 8 erlautert. Die Objektmanager-Kompo- 45 ganglich zu machen, ist es vorgesehen, daB jede Objektma- 

nente 6 arbeitet bei der Oberwachung als Client fiir die Ob- nager-Komponente 4 bis 16 oder jeder Objektmanager in^ 

jektmanager-Komponente 8 und als Server fur die Objekt- dem entsprechenden Server-Hauptteil 38 eine Schnittstelle 

manager-Komponente 4. Die Objektmanager-Komponenten aufweist, die eine Anderung des Redundanz-Zustandes der 

4 bis 16 sind zur Oberwachung ihres Zustandes in einem lo- jeweils anderen Objektmanager-Komponenten oder Objekt- 

gischen Ring angeordnet, so daB keine iibergeordnete Uber- 50 manager erfaBt, 

wachungskomponeiite erforderlich ist Die Oberwachung Insbesondere fur die Handhabung einer sicheren Daten- 

erfolgt nach dem Client-Server Prinzip. Die als Client arbei- ubertragung von redundant ausgefuhrten Objektmanager- 

tende Objektmanager-Komponente 6 sendet in definierten Komponenten ist die Infrastruktur 2 derart ausgestaltet, daB 

Zeitabstanden ein Signal (Objekt) an die entsprechend als die Ubermittlung eines datenlesenden Auftrages selbsttadg 

Server ausgebildete Objektmanager-Komponente 8. Diese 55 an den prozefifuhrenden Server erfolgt. Hierzu dient bei- 

Komponente 8 sendet daraufhin ein "Lebenszeichen" an die spiels weise der Eintrag in der vorstehend genannten Schnitt- 

Komponente 6. In gleicher Weise erhalt die Kornponente 6 stelle beziiglich des Zustands einer Objektmanager-Kompo- 

von der Kornponente 4 in definierten Zeitabstanden eine nente oder eines Objektmanager s. Gleichzeidg sorgt die In- 

Aufforderung, ein "Lebenszeichen" zu senden. Zur Server- frastruktur 2 dafiir, daB die Ubermitdung eines datenschrei- 

suche lauft auf alien Objektmanager-Komponenten 4 bis 16 60 benden Auftrages an alle zueinander redundanten Objekt- 

der gleiche Algorithmus ab, beispielsweise konnen die Ob- manager-Komponenten oder Objektmanager erfolgt, so daB 

jektmanager-Komponenten 4 bis 16 ihren Uberwacher und der nicht prozeBfuhrende Teil jederzeit in der Lage ist, die 

den zu Uberwachenden anhand der alphabedschen Reihen- ProzeBfuhrung zu ubemehmen. 

folge ihrer Benennung ermitteln. Auch der logische Ring ziir Oberwachung der Objektma- 

In Fig. 4 ist eine gegenuber Fig. 3 geringfugig modifi- 65 nager- Komponenten 4 bis 16 schlieBt sich bei dem Ausfall 

zierte Konfiguradon des Systems 18 dargestellt. Hier sind der Objektmanager-Komponente 10a selbsttadg, weil die 

die Objektmanager-Komponenten 6 und 10a ausgefallen. Objektmanager-Komponenten 4 und 12a, 12b automadsch 

Der Server der ausgefallenen Objektmanager-Komponente auf die redundante Objektmanager-Komponente 10b um- 
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schalten, die ihren Zustand von "nicht-prozeBfiihrend" nach 
"prozeBfiihrend" geandert hat, wie dies die Pfeile 46, 48 
symbolisieren. 

In Fig. 5 ist nochmals der Logische Ring zur Uberwa- 
chung der Objektmanager-Komponenten 4 bis 16 schema- 5 
tisch dargestellt. Hierbei soli deutlich gemacht werden, daB 
die Uberwachung in zwei Uberwachungsebenen erfolgt. In 
der ersten ttberwachungsebene uberwachen sich die Objekt- 
manager-Komponenten 4 bis 16 selbsttatig im gemaB Fig. 3 
beschriebenen Ring. Dies ist in Fig. 5 durch die Pfeilverbin- 10 
dungen von Objektmanager-Komponente zu Objektmana- 
ger-Komponente symbolisiert. 

An der hier ausgewahlten Objektmanager-Komponente 
14 ist die zweite Uberwachungsebene schematisch darge- 
stellt. Innerhalb einer Objektmanager-Komponente werden 15 
zyklisch wiederkehrend die Zustande der einzelnen lokal in- 
stallierten Objektmanager, hier der redundant ausgefuhrte 
Protokollverwalter 24a, 24b und die Datenbank 28 fur Be- 
schreibungsdaten, iiberwacht. Auf diese Weise ist eine Ent- 
kopplung der Uberwachungsprozesse fur Objektmanager- 20 
Komponenten und Objektmanager erreicht, so daB bei- 
spielsweise nach dem Ausfall eines einzelnen Objektmana- 
gers nicht die gesamte Objektmanager-Komponente als aus- 
gefallen gemeldet werden muB. 

25 

Patentanspriiche 

1. Infrastruktur (2) fur ein System von verteilten Ob- 
jektmanager-Komponenten (4 bis 16), insbesondere fiir 
ein Leitsystem einer Kraftwerksanlage, mit einer An- 30 
zahl von rechnergestiitzten Objektmanager-Kompo- 
nenten, die jeweils mindestens einen Objektmanager 
ausfiihren, wobei fur redundant ausgefuhrte Objektma- 
nager-Komponenten (10a, 10b, 12a, 12b) oder Objekt- ■ 
manager (22a, 22b, 24a, 24b) der Zustand "prozeBfuh- 35 
rend" und entsprechend "nicht-prozeBfuhrend" iiber-- 
wacht und fur alle iibrigen Objektmanager- Komponen- 
ten (4, 6, 8, 14, 16) zuganglich ist. 

2. Infrastruktur (2) nach Anspruch 1, dadurch gekenn- 
zeichnet, daB ein Zustandsiibergang einer Objektmana- 40 
ger-Kornponente (10a, 10b, 12a, 12b) oder eines Ob- 
jektmanagers (22a, 22b, 24a, 24b) bei Vorliegen eines 
Ausfailereignisses selbsttatig erfolgt. 

3. Infrastruktur (2) nach Anspruch 1 oder 2, dadurch 
gekennzeichnet, daB die Ubermittlung eines datenle- 45 
senden Auftrages an den jeweils prozeBfuhrenden Ser- 
ver einer Objektmanager-Komponente oder eines Ob- 
jektmanagers erfolgt. 

4. Infrastruktur (2) nach einern der Anspriiche 1 bis 3, 
dadurch gekennzeichnet, daB die Ubermittlung eines 50 
datenschreibenden Auftrages an alle zueinander redun- 
danten Objektmanager-Komponenten (10a, 10b, 12a, 
12b) oder Objektmanager (22a, 22b, 24a, 24b) erfolgt. 

5. Infrastruktur (2) nach einern der Anspriiche 1 bis 4, 
dadurch gekennzeichnet, daB zum Aufdaten von Ob- 55 
jektmanagern (20, 26) auf wiederanlaufenden redun- 
danten Objektmanager-Komponenten der fiihrende 
Server auf Auftrag ein konsistentes Abbild seiner Pro- 
zeBdaten erstellt und zum aufrufenden Client ubertragt. 

6. Infrastruktur (2) nach Anspruch 5, dadurch gekenn- 60 
zeichnet, daB eine Objektmanager-Komponente (10a, 
10b, 12a, 12b) oder ein Objektmanager (22a, 22b, 24a, 
24b) in einern Server-Hauptteil (38) eine Schnittstelle 
(36) aufweist, die eine Anderung des Redundanz-Zu- 
standes erfaBt. 65 
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